Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Embodiments relate to resource access by a plurality of applications, and in particular to a resource registry having a feedback feature allowing implementation of a nondeterministic operation execution environment.
In certain contexts, a single resource may be sought to be shared between a plurality of different applications. For example, Customer Resource Management (CRM) and Enterprise Resource Management (ERM) applications may seek to perform operations on data (e.g., customer contacts, customer accounts, customer addresses, etc.) that are held in common within a same in-memory database.
Typically, while the resource (operation executor) is responsible for performing the operation itself, that operation executor and an operation requestor (e.g., an application) must exchange some information. For example, a resource may comprise an in-memory database whose engine is responsible for executing an operation (e.g., data aggregation, etc.).
In order to continue to function, the requester of the operation (e.g., a CRM application) may need to know the status of the operation (e.g., whether an aggregation is in-progress, has been successfully completed, or is unable to be successfully completed).
Another example of the exchange of information between an operation requestor and an operation executor, includes providing roles and/or permissions to be imported in a target system. Still other examples involving exchange of information between operation requestors and executors, include providing and importing Meta-data Framework (MDF) objects to a target system, and the discovery and registration of specific objects.
Conventionally, such activities are performed with direct calls between the operation requestor and the operation executor. However, issues can arise within such (deterministic) resource environments requiring direct communication between requestor and executor.
For example, the requester needs to know the exact Uniform Resource Locator (URL) of the executor (e.g., the location of the in-memory database on the cloud). That URL, however, may change/evolve over time—e.g., as the in-memory database expands and is migrated into a larger capacity space.
Also, the executors and the requesters of operations can comprise a large number of different types of applications. Ensuring the ability for direct communication between such a variety of entities can render the configuration setup complex and error-prone.
Finally, different executors may provide different Application Program Interfaces (APIs) for the execution of an operation. This specificity in API limits flexibility in the allocation of resources between a plurality of operation requestors and operation executors, for example as may arise in a cloud computing environment.